Subject: Flow control scope

From: [email-masked]
Date: Wed, 14 Jul 93 08:24:29 EDT

Bernie,
You have raised some good questions.  Before I throw out some thoughts,
let me say I am more accustomed to the terminology you were using in
the first version.  As I look through the RFC I can see that its
usage of "circuit" and "connection" is very confusing.  I think many
RFC references to "establishing a connection" were meant in the
everyday sense of "put into the connected state".  I will check with
Roy Dixon to see if he'd like to make a clarification.  In the meantime,
to avoid confusion in this discussion I suggest we use "circuit" to
mean the end-to-end association of two DLC link stations through two
DLSw routers, and "transport connection" to be the vehicle between
the routers.  Note that the 6611 implementation uses two TCP connections
in simplex mode to make up what I'm calling a transport connection.

You are correct that NCP supports a local SNA SAP of x'04' only, and
remote SAPs which are non-zero and non-reserved multiples of 4 (both for
connect-out and connect-in).  The only negative consequence I can see
to their local SAP limitation is that it forces a remote product to
have to implement multiple SAP support itself, if that product wants
multiple LLC2 connections from the same MAC address on the product to
the same TIC on the NCP.  The NCP guys didn't see that very many
products would need that multiple-links-between-the-same-mac-addresses
capability so they left it to the end stations.  I agree it would have
been nice if they'd supported multiple local SAPs, but I don't see how
their choice can be seen as a bug.

NCP's support does not limit a DLSw router to 64 circuits per transport
connection.  The DLSw router presents the appearance to NCP of both the
MAC and SAP of the remote link station;  it is not terminating all the
LLC connections using its own MAC address.  The limitation of about 64
circuits applies to a single port (MAC address) on the LAN-attached
product that the NCP-side DLSw router is representing.	This is the
same limitation the product would have directly connected to the NCP.
If the SIG decides to limit the number of circuits on a transport
connection (per Scott Adams' concerns in aiw-sig-dlsw), I don't think
addressing will be the limiting factor.

On the topic of current product support, I think I need to clarify where
the 6611 is today on flow control.  None of the pacing algorithms we've
been discussing are operational in the field;  the 6611 is not today
setting those bits in the DLSw header, nor is it sending ENTERBUSY and
EXITBUSY over the WAN in response to a LAN link station sending it an
RNR.  ENTER/EXITBUSY do flow to avoid certain link establishment race
conditions, as I've mentioned before.  What the 6611 does do is watch
queue depths on a circuit basis (as well as monitor various other buffer
conditions) and send RNRs/RRs to link stations accordingly.  This can
all work because the 6611 uses a virtual memory model and doesn't need as
tight a control on memory usage as most other router implementations.
The pacing scheme we've been working from was coded and partially tested,
however, and I feel has been a good starting point for discussions here.

I fully agree that defining only a circuit-level flow control mechanism
is a minimalist approach, and there may be some conditions that would
be more efficiently handled with, say, transport connection-level
signals.  The question in my mind is simply what those conditions might
be and whether they would justify making everyone implement the logic.
I have thought about a destination token-ring beaconing, requiring a
halt on all circuits going to that LAN segment, but that wouldn't be
transport-connection level.  The scenario I'm guessing you have in mind
is severe box-wide buffer congestion at the receiver, and I agree in this
case you wouldn't want to have to generate a bunch of new flow control
frames to send IPMs on every circuit.  I was thinking you might get by,
though, only doing flow control on the circuits with traffic flowing at
the moment and not sending on every established circuit.  What do people
think?	If the consensus is we need a transport connection-level signal
I don't think it's hard to do.  Maybe there would be some undesirable
interactions with TCP/other transport flow control - does anyone see
problems in that area?

(A couple quick thoughts from APPN design:  ISR session pacing required
a tiny IPM-sized buffer to be reserved for the life of a session so
we could guarantee a buffer to send a "slam" IPM in severe congestion
situations.  I never liked this much but it is a way to avoid trying
to get buffers when severely congested.  If we're real adventurous we
could reflect box congestion in ICR messages to discourage new circuit
establishment through congested boxes when an origin DLSw gets back
multiple ICRs and has to pick one.)

I talked with Gene Cox some about the LLC1 versus LLC2 issue.  It's not
a problem if all you're running is SNA, which sends very few UI-frames,
but it can be a big problem if NetBIOS is anywhere on a transport
connection.  The pacing scheme we've been discussing doesn't really
address the issue since it was written only for I-frame traffic.  The
6611 has handled it various ways but I don't have a standard solution
to propose at this point.  I need to understand the issue better, and
look forward to reading people's comments on it.

Peter Gayek

---

From: [email-masked] (Susie Kim Riley)
Date: Wed, 14 Jul 93 10:24:25 EDT

"
...... In the meantime,

"

__________________________________________

In the RFC, the transport connection section seems inadequate and vague.  It
does not explicitly say that there should be two TCP connections in
simlex mode.  Instead it says..

"Before Data Link Switching can occur between two routers, they must
establish A TCP CONNECTION between them..."

Even the document refers to it as one TCP connection.  Then later, it
goes on to specify a read port of 2065, and a write port of 2067.

Please clarify...

skr